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REMARKS 

The Examiner has rejected Claims 1-24 under 35 U.S.C. 103(a) as being 
unpatentable over Johnson, U.S. Patent 6,469,704, in view of Deering, Michael R, 
and Nelson, Scott R., Leo: A System for Cost Effective 3D Shaded Graphics » 
Applicant respectfully disagrees with such rejection, especially in view of the 
amendments made hereinabove. 

In particular, applicant has incorporated the subject matter of Claims 2 and 3 
into independent Claims 1, 8, 15-17, and 24. Now claimed is "graphics floating 
point data [which] includes fragment data received from a rasterizer that is . . . stored 
in an undamped format" (emphasis added). The Examiner relies on various 
excerpts from Johnson to meet applicant's claimed "fragment data received from a 
rasterizer." However, nowhere in the cited excerpts is there mention of any sort of 
fragment data, let alone "fragment data received from a rasterizer." 

Even if such language or its equivalent was present in Johnson, the 
Examiner's proposed combination would still fail to meet applicant's claim 
limitations. Deering merely teaches operating on vertex data in various IEEE 
floating-point formats. Thus, the Examiner's Johnson-Deering combination would 
fail to meet applicant's specifically claimed "graphics floating point data [which] 
includes fragment data received from a rasterizer that is . . . stored in an undamped 
format" (emphasis added). 

Deering's vertex data processing teaches away from the non-analogous 
technique of storing fragment data received from a rasterizer in an undamped 
format. Thus, only applicant teaches and claims the unobvious technique of 
fragment data processing in an undamped format. As set forth in the originally filed 
specification, most computations dealing with fragment data are typically 
constrained to operate on values in the range [0,1]. Computational results are also 
typically clamped to the range [0,1]. Color, texture, and depth buffers themselves 
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also hold values mapped to the range [0, 1]. Unfortunately, these constraints and the 
limited precision of typical computations can result in reduced accuracy during 
graphics processing. 

To further distinguish applicant's claimed invention, applicant now claims an 
"undamped format dictated by a graphics application program interface " (emphasis 
added). While Deering merely teaches support for the conversion of multiple 
numeric formats to 32-bit IEEE floating-point for traditional vertex computations, 
applicant teaches and claims a fragment-specific undamped format in association 
with a graphics application program interface. Thus, applicant's claimed invention 
permits external access and control of applicant's "undamped" format for advanced, 
fragment-specific computations in the specific context of graphics floating point data 
which includes fragment data received from a rasterizer. 

Only applicant teaches such a combination of features for fulfilling the 
foregoing objectives. To further emphasize these distinctions, applicant has 
amended Claim 24 to include further graphics application program interface details. 
A specific prior art showing of such limitations or a notice of allowance is 
respectfully requested. 

With respect to Claims 7, 14, 18 and 19, the Examiner relies on the following 
excerpts from Deering to show in the prior art applicant's claimed buffer capable of 
storing graphics floating point data in a graphics pipeline, "wherein the buffer serves 
as a texture map " (emphasis added). 

*Here the concept is that multiple parallel computation units 
can each process the entire floating-point intensive task, 
working in par-allel on different parts of the scene to be 
rendered. This allows each pipe to be given a large task to 
chew on, minimizing handshake overhead." (Page 102, left col., 
second para., lines 2-4) 

"The LeoFloat chips are microcoded specialized DSP-like 
processors that tackle the floating-point intensive stages of 
the rendering pipeline. The LeoDraw chips handle all screen 
space pixel rendering and are directly connected to the frame 
buffer RAM chips. LeoCross handles the back-end color look-up 
tables, double buffering, and video timing, passing the final 
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digital pixel values to the RAMDAC." (Page 102, right col . , 
lines 4-10) 

"To save IC pins and PC board complexity, the internal Leo 
data bus-ses connecting LeoCommand, LeoFloat, and LeoDraw are 
16 bits in size. When colors, normals, and texture map 
coefficients are being transmitted on the CF-bus between 
LeoCommand and the Leo- Floats, these components are 
(optionally) compressed from 32-bit IEEE floating-point into 
16 -bit fixed point fractions by Leo-Command, and then 
automatically reconverted back to 32-bit IEEE floating-point 
values by LeoFloat. This quantization does not effect quality- 
Color components will eventually end up as 8 -bit values in the 
frame buffer. For normals, 16-bit (signed) accuracy represents 
a resolution of approximately plus or minus an inch at one 
mile. This optimization reduces the required data transfer 
bandwidth by 25%." (Page 104, left col., third para., lines 1- 
12) 

"These are mapped directly into microcode register space. 
Special instructions allow complete packets to be requested, 
relinquished, or queued for transmission in one instruction 
cycle." (Page 104, right col., fifth para., lines 5-7) 



It appears that the Examiner has simply gleaned various keywords from such 
different portions of the Deering reference. Simply nowhere in these excerpts or the 
remaining reference is there disclosed, taught or suggested applicant's claimed 
floating-point " buffer l"that| serves as a texture map" (emphasis added). Applicant 
has further emphasized this distinction with the addition of Claim 25 which requires 
that "the buffer serves as a texture map by using previous rendering results via an 
extension of an application program interface" (see Claim 25). A specific prior art 
showing of such limitations or a notice of allowance is respectfully requested. 



With respect to the subject matter of Claims 22 and 23, the Examiner has 
relied on a mention of "pixel-packing conventions" in Johnson to make a prior art 
showing of applicant's claimed "unpacking/packing the graphics floatingpoint data 
in the graphics pipeline." To clarify applicant's unique "packing/unpacking," 
applicant now claims "wherein the packing/unpacking facilitates storage of at least 
two quantities in a single buffer in a single pass." A specific prior art showing of 
such limitations or a notice of allowance is respectfully requested. 
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AU of the independent claims are now deemed allowable along with any 
claims depending therefrom. An allowance of all pending claims is respectfully 
requested. 

In the event a telephone conversation would expedite the prosecution of this 
application, the Examiner may reach the undersigned at (408) 505-5 1 00. The 
Commissioner is authorized to charge any additional fees or credit any overpayment 
to Deposit Account No. 50-1351 (Order No. NV1DP069). 



P.O. Box 721120 

San Jose, CA 95172-1120 

408-505-5100 
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